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(54) Abstract Title: Multicast group management in paclcet radio networl<s 

(57) In a packet radio network (1) comprising a radio access network (5) and a core network ON (2) via which a 
plurality of mobile nodes (12) may communicate over a wireless link with an external packet data network 
(8), a method of administering at least one multicast group, subscribers of which are from said plurality of 
mobile nodes (12), which method comprises the steps of: 

(1 ) maintaining a first database of subscribers of each multicast group at a first node (3) in said 
packet radio network, said database enabling identification of the or each second node (4), or any other 
network node on the packet radio network, responsible for the subscribers of each multicast group; 

(2) providing a mapping between subscribers of each multicast group and a number of multicast 
logical links between the first node (3) and the or each second node (4); 

wherein, where there is more than one subscriber of a multicast group served by a second node (4), 
the first database maps those subscribers to a number of multicast logical links (11) that less than the 
number of those subscribers. 
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METHOD, NETWORK NODE AND COMPUTER PROGRAM FOR 
MULTICAST GROUP MANAGEMENT IN A PACKET RADIO NETWORK 

FIELD OF THE INVENTION 

The present invention relates to a method of administering at least one 
multicast group, to a network node for use in such a method, to a computer program 
for executing the method and to a product comprising the computer program. 

BACKGROUND OF THE INVENTION 

Mobile communications systems are generally any telecommunications 
system that enables wireless communication by users with mobile devices (or nodes), 
moving or stationary, in the service area of the system. Often the mobile 
communications network is an access network providing a user with wireless access 
to external networks, hosts, or services offered by specific service providers. Mobile 
devices include cellular phones, personal digital assistants (PDAs), notebook 
computers and digital cameras for example. 

The Universal Mobile Communications System ("UMTS") is presently being 
developed as a member of the global family of third generation ("3G") mobile 
technologies identified by the International Telecommunications Union (ITU) . The 
UMTS architecture comprises a UMTS terrestrial radio access network (UTRAN) 
and a backbone core network (CN), which together provides a bearer network. The 
UTRAN provides the radio interface and the physical radio resources for user 
equipment (UE). The UTRAN is connected to the CN that provides various 
telecommunications services such as data, speech and messaging services. The CN 
may be a circuit-switched (CS) domain network or a packet-switched (PS) domain 
network. The PS backbone network will provide the UE with Internet Protocol (IP) 
connectivity services. Thus the UE can establish an IP connection to any IP host, IP 
network or IP service via the 3G access network. 

The UMTS CN infrastructure comprises support nodes such as the gateway 
GPRS support node (GGSN) and serving GPRS support node (SGSN). A SGSN is 
connected to the UTRAN so that the SGSN can provide a packet service for mobile 



UE. The UTRAN provides radio access and packet-switched data transmission 
between the SGSN and UE. The CN is in turn connected to an external data network, 
for example to a public switched packet data network PSPDN via the GGSN. The 
UMTS service thus allows packet-switched data transmission to be provided between 
mobile nodes and external data networks while the UTRAN provides radio access 
over a wireless link. 

The main functions of the SGSN are to detect new mobile stations in its 
service area, handle the process of registering new UEs, send/receive data packets 
to/from the UEs, and to keep a record of the location of the UEs inside its service 
area. In order to access the UMTS services, a UE first makes its presence known to 
the network by performing the PS attach procedure. This operation establishes a 
mobility management context as well as a routing context at the UE and the SGSN. 
The MM context of the SGSN may contain subscriber data such as the subscriber 
identity, location information etc. 

The main functions of the GGSN involve interaction with the external data 
networks. The GGSN may also be connected directly to a private corporate network 
or host for example. The GGSN includes PDP addresses and routing information i.e. 
SGSN addresses for active subscribers. The GGSN updates the location directory 
using routing information supplied by the SGSNs. The GGSN uses the routing 
information for tunnelling the protocol data units (PDUs) from the external networks 
to the current location of the UE i.e. to the serving SGSN. The tunnelling means that 
the packet data is encapsulated into another data packet during transfer from one end 
of the tunnel to another. The GGSN also decapsulates data packets from UEs and 
forwards them to the appropriate data network. In order to send and receive data, the 
UE activates the packet data address that it wants to use by requesting a "PDP 
activation procedure". This operation makes the UE known in the corresponding 
GGSN, and internetworking with other networks can commence. More particularly, 
one or more PDP context is created in the UE, GGSN and SGSN and stored in the 
serving SGSN in connection with MM context. The PDP context defines different 
data transmission parameters, such as PDP type (e.g. PPP or IP), PDP address (e.g. IP 
address) and quality of service (QoS). Two associated PDP contexts in different 
GSNs are used as endpoint records for a GTP tunnel. The tunnel is identified with a 
Tunnel Endpoint ID (TEID). The UE activates the PDP context with a specific 



message. Activate PDP Context Request, in which it gives information on the PDP 
type, PDP address and required QoS, and optionally the access point name APN. The 
SGSN sends a create PDP context message to the GGSN which creates the PDP 
context and sends it to the SGSN. The SGSN sends the PDP context further to the UE 
in an Activate PDP Context Response message, and a virtual connection or logical 
link between the UE and the GGSN is established. The PDP context is stored in the 
UE, the SGSN and the GGSN. As a result the SGSN tunnels all the data packets from 
the UE to the GGSN, and the GGSN tunnels to the SGSN all data packets received 
from the external network and addressed to the UE. 

The exact way in which a UMTS network will be deployed will be decided by 
the network operator. However, it is generally envisaged that a GGSN will be 
connected to the Internet at large, in a similar way to a Local Area Network (LAN) 
for example, thereby giving mobile users access to the Internet. It is expected that a 
GGSN may support of the order of approximately 200,000 active connections; a 
SGSN may support of the order of 50,000 active connections and a RNC may support 
of the order of hundreds of base stations, e.g. 150 to 550. 

Hosts frequently demand transmission of the same data on the same 
downlink. For example, businessmen at a conference may all require simultaneous 
access to a webcast, videoconference, files, stock quotes, Internet audio and 
multimedia from their respective mobile terminals. Other groups of hosts may require 
simultaneous access to details of sports events for example, as they happen in real- 
time. Packet data to each of these groups may be sent to each user in the group with 
unicast messages. For example, if ten businessmen in a hotel wish to view a live 
webcast, the packet data of the webcast can be sent ten times from the Internet host in 
total. This is clearly inefficient in terms of network resources. 

Multicast or group communication protocols have been designed for packet- 
switched networks to overcome this problem by supporting point-to-multipoint data 
transfer. Multicasting can be defined as a one-to-many (or many-to-many) type of 
communication, i.e. the transmission of the same information from one or multiple 
senders to several destinations. With multicasting, a sender's data stream is 
transmitted only once on links that are shared along the paths to a targeted set of 
destinations. This data stream is duplicated at the points (e.g. routers for IP networks) 



- 4 - 



where the paths diverge in order to reach receivers located on different networks or 
sub-networks. Muhicasting offers efficient multi-destination delivery since data is 
transmitted in an optimal manner with minimal packet duplication. 

5 The most widely deployed multicast protocol in use today is Internet Protocol 

(IP) multicast. IP is the protocol by which data is sent from one computer to another 
on the Internet. Both IP version 4 (IPv4) and IP version 6 (IPv6) provide inbuilt 
support for point-to-multipoint or multicast connections. IP multicasting is defined as 
the transmission of an IP datagram to a "host group", a set of zero or more hosts 

10 identified by a single IP destination address. The membership of a host group is 
dynamic; that is, hosts may join and leave groups at any time. There is no restriction 
on the location or number of members in a host group, but membership in a group 
may be restricted to only those hosts possessing a private access key. A host may be a 
member of more than one group at a time. A host need not be a member of a group to 

15 send datagrams to it (see RFC 1112). 

For example the IP multicast protocol would permit, in the example above, 
only one transmission of the webcast packet data over the Internet until the last router 
where the packets would be copied and sent to each of the ten users. 

20 

Fundamental to all multicasting protocol is the concept of a process (i.e. an 
application associated with a host) joining a multicast group. The Internet Group 
Management Protocol (IGMP) (RFC 2236) and Multicast Listener Discovery (MLD) 
(RFC 2710) are protocols for IP Version 4 (IPv4) and IP Version 6 (IPv6) 

25 respectively that allow a host to inform its local router that it wishes to receive 
transmissions addressed to a specific multicast group. IGMP and MLD run between 
hosts and neighbouring multicast routers. Based on the group membership 
information learned from IGMP or MLD, a router is able to determine which (if any) 
multicast traffic needs to be forwarded to each of its "leaf sub-networks (i.e. the sub- 

30 networks that have no further downstream routers). A multicast routing protocol is 
executed on routers to construct packet delivery paths and to accomplish packet 
forwarding to the multicast recipients. IGMP is considered part of the IP layer. IGMP 
messages are transmitted in IPv4 datagrams. 



35 



The functionality of IGMP is based on report and query messages that are 



exchanged between hosts and their neighbouring routers. When a host on a given 
interface (i.e. a sub-network) wants to join a multicast group, the host sends an IGMP 
report to the neighbouring muhicast router. A muhicast router sends an IGMP query 
at regular intervals to see if hosts stilt have processes belonging to any groups. 

Applying either the IGMP or the MLD protocol to UMTS networks results 
in inefficient multicast routing and group management. The principle disadvantage is 
that network-layer routing (i.e. selecting the transmission path for the ''next hop" in 
the route) within the UMTS network is not based on the evaluation of IP headers and 
is therefore not IP-based. UMTS network-layer routing is implemented by 
encapsulating and subsequently tunnelling IP packets between network nodes. In 
encapsulating IP packets, a new header containing tunnelling information is added to 
the packet, thus effectively rendering the initial IP header "invisible" to the UMTS 
network. Only at the network gateway (GGSN) is the actual IP header processed for 
the purpose of packet exchange with external networks. Bearing in mind that IGMP 
messages are encapsulated in IP packets and therefore cannot be processed by 
intermediate UMTS network nodes, IGMP or MLD messages must traverse the entire 
network until they reach the network gateway before any action in response to the 
join/leave request can be taken. This is clearly inefficient. 

Furthermore, the use of tunnels between UMTS network nodes does not lend 
itself toward resource-efficient multicast message delivery as each individual tunnel 
established between the respective network nodes maps to a single subscriber within 
the network in a one-to-one relationship. Applying the tunnelling mechanism for one- 
to-many message delivery from a single source to a group of m subscribers in the 
downlink direction is equivalent to m times unicast. Therefore m duplicates of the 
multicast messages are transmitted across the UMTS network since the multicast 
address is ''hidden" by the GTP (GPRS Tunnelling Protocol) headers used by the 
UMTS network nodes. 

"IP Multicast in UMTS" by M. Hauge and O. Kure (see 
www.unik.no/-mariannh/Artikler/IP%20Multicast%20in%20UMTS.pdn discloses 
UMTS architecture in which the RNC acts as the terminating node for the IP 
multicast protocol. It is suggested that multicast data will be forwarded using 
multicast data distribution in the Core Network and unicast data distribution from the 
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RNC to each UMTS multicast subscriber. However, it is not apparent from this 
document how the logical link between the GGSN and RNC will be handled. Packets 
arriving at the GGSN must be associated with a PDP context, otherwise they are 
silently discarded. Since PDP contexts are only associated with a single user, it is not 
5 clear how multicast packets arriving at the GGSN will be handled. 

WO 00/57601 discloses a method for forwarding a multicast message 
received from an external data network (PDN) to subscribers of a packet radio 
network. Subscriber-specific information defining multicast messages to be received 

10 by the subscribers is stored in the GGSN. Based on this subscriber-specific 
information, a point-to-point connection is established between each subscriber and 
the GGSN for delivery of multicast messages. This enables PDUs addressed to a 
multicast address to be delivered to subscribers over the packet radio network. 
However, a multicast packet must be duplicated at the GGSN for each multicast 

15 subscriber. Thus no saving is made on bandwidth over the packet radio network, even 
though there may be several subscribers to the same multicast group served by the 
same SGSN. 

WO 02/51072 discloses an IP-based group communication procedure based 
20 on pre-established logical connections between a GGSN and members of a group in a 
UMTS network. PDP contexts of the members of a group are associated and stored at 
the GGSN. VoIP data addressed to the multicast address of the group is sent by one 
member to a multicast router on an external PDN, via that member's PDP context. 
The multicast router forwards the VoIP packets to the members of the group. The 
25 multicast packets are received by the GGSN that maps the multicast address to the 
PDP contexts of the members of the group. The GGSN then sends copies of the VoIP 
packets to each member of the group (apart from the sending member) through their 
respective logical connections. Thus it is apparent that in this method packets are 
copied at the GGSN and no benefits of a multicast transmission protocol are realised 
30 over the UMTS network. 

From the foregoing it is apparent that there is a need for an improved UMTS 
network that supports point-to-multipoint or muhicast message delivery. There is also 
a need for such a network where the same or similar benefits of a multicast protocol 
35 on a PDN are obtained, at least partly, on a packet radio network. 



There is yet further a need for a packet radio network that supports IP-based 
multicast protocols but that does not necessarily need to implement IP-based 
multicast group management protocols such as IGMP or MLD. 

SUMMARY OF THE PRESENT INVENTION 

Multicast Routing 

Preferred embodiments of the present invention aim to provide support for 
multicast at the packet radio layer, thereby reducing the amount of processing 
necessary by nodes in the network. The present invention aims to reduce the amount 
of processing of multicast join or leave messages and therefore offers improved 
performance over alternative solutions based on IGMP. Preferred embodiments of the 
invention provides a mechanism for overcoming this inherent lack of support for 
resource-efficient multicast message delivery by establishing tunnels across the On 
and lu interfaces that map to a multicast group (i.e. a plurality of subscribers) instead 
of to a single subscriber, thereby avoiding duplicate transmissions of multicast 
messages across the On and lu interfaces of the network. 

The present invention includes a method of multicast routing for a packet 
radio network, and more particularly but not exclusively a UMTS network. Preferred 
embodiments of the present invention employ new multicast routing procedures at 
the packet radio layer or PDP layer that lies above the UDP/IP layer in the packet 
radio network. Thus nodes in the packet radio network do not need to use IGMP, 
MLD or any other IP multicast group management protocols in order to handle 
multicast traffic arriving from external packet data networks. 

According to the present invention there is provided, in a packet radio 
network comprising a radio access network (RAN) and a core network (CN) via 
which a plurality of mobile nodes may communicate over a wireless link with an 
external packet data network, a method of forwarding multicast packet data units (M- 
PDUs) for a multicast group to at least one subscriber mobile node subscribed to the 
multicast group, which method comprises the steps of: 

( 1 ) receiving an M-PDU at a first node (GGSN) in said CN; 
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(2) identifying at least one second node (SGSN) responsible for said at 
least one subscriber mobile node; and 

(3) where a second node (SGSN) serves multiple subscriber mobile 
nodes, forwarding said M-PDU from the first node (GGSN) to the or each second 

5 node (SGSN) via a number of multicast logical links that is less than the number of 
subscriber mobile nodes of the multicast group served by each second node (SGSN) 
respectively. There may be a number of multicast logical links per SGSN. For 
example, the number of multicast logical links between the GGSN and each SGSN 
may equate to differing qualities of service. Where the first node is a GGSN, the M- 
10 PDU is a multicast packet, for example an IP multicast packet received from the 
Internet. Accordingly whilst the term multicast packet data unit (M-PDU) is 
primarily intended to cover multicast packets transmitted over a packet radio 
network, it may also include IP multicast packets per se. The multicast logical links 
may be M-PDP contexts and/or M-RAB contexts as defined herein. 

15 

Preferably, said M-PDU is forwarded to the or each second node (SGSN) 
responsible for said at least one subscriber mobile node via a single multicast logical 
link per second node (SGSN). This helps to reduce network resources consumed by 
multicast traffic. In particular, multicast packets need only be sent once on each 
20 multicast logical link and in total a number of times equivalent to the number of 
SGSNs serving subscribers to the multicast group. This is in contrast to existing 
support for multicast in packet radio networks in which the multicast packet must be 
replicated at the GGSN for each user that is subscribed to the group. 

25 Clearly there may arise occasions where there is only one subscriber to a 

multicast group per SGSN. In this scenario the invention provides a dedicated logical 
link for multicast packets for that subscriber. However, as soon as there are a 
plurality of subscribers to one multicast group that are served by the same SGSN, 
multicast packets for that group may be forwarded from the GGSN to that SGSN 

30 over a number of logical links that is less than the number of subscribers. In one 
embodiment, there is only one logical link that provides a dedicated multicast logical 
link such that, no matter how many subscribers join the multicast group, the M-PDU 
need only be transmitted once over the dedicated link of those subscribers. 

35 Advantageously, the method further comprises the steps of, at the or each 
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second node (SGSN), identifying at least one third node (RNC) responsible for said 
at least one subscriber mobile node, and where a third node (RNC) serves multiple 
subscriber mobile nodes, forwarding said M-PDU from the second node (SGSN) to 
the or each third node (RNC) via a number of multicast logical links that is less than 
5 the number of subscriber mobile nodes of the multicast group served by each third 
node (RNC) respectively. This has the same advantages as for the link between the 
first node (GGSN) and the or each SGSN as described above in that less network 
capacity is consumed by multicast traffic. In UMTS there will be two multicast 
logical links, one between the GGSN and SGSN and the other between the SGSN 
10 and the RNC. As used herein the term "multicast logical link" is intended to cover a 
link comprising one or a number of segments. 

In one embodiment, said M-PDU is forwarded to the or each third node 
(RNC) responsible for said at least one subscriber mobile node via a single multicast 
1 5 logical link per third node (RNC). 

Preferably, the method further comprises the steps, upon receipt of said M- 
PDU at the first node (GGSN), of searching a database for records of multicast 
logical links maintained by the first node (GGSN) for a record that references the 
20 multicast address of said M-PDU. In this way, multicast traffic can be associated 
quickly with the dedicated multicast logical link. The search may be performed on 
the basis of the IP multicast address of the incoming packet for example. 

Advantageously, each record contains a list of multicast subscriber entries for 
25 a particular multicast group, each multicast subscriber entry containing a reference to 
a first active logical link associated with the subscriber mobile node of that entry, and 
wherein said reference is used to look up the first active logical link for each 
multicast subscriber entry and extract the identity of the responsible second node 
(SGSN). By making reference (for example with a pointer) to the individual logical 
30 link of each subscriber, network resources are saved as the record does not have to 
store mobility parameters or be update after inter-SGSN handover. Each time the first 
active logical link is looked up, the record returns the most up to date SGSN for that 
subscriber. 



35 



Preferably, said reference comprises the Network Service Access Point 
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(NSAPl) and/or International Mobile Subscriber Identity (IMSI) and/or Tunnel 
Endpoint Identifier (TEID), and said first active logical link comprises the PDP 
context associated with said subscriber mobile node between the first node (GGSN) 
and the responsible second node (SGSN). In this way, the existing logical links that 
5 must be established for each mobile node to communicate over the packet radio 
network are utilised. 

Advantageously, the method further comprises the steps of creating a list 
containing the identity of the or each second node (SGSN) responsible for said at 
10 least one subscriber mobile node, removing duplicate identities from said list, and 
replicating and forwarding said M-PDU to the or each second node (SGSN) 
remaining on the list. In this way multicast traffic need only be transmitted once or a 
small number of times over each multicast logical link. 

15 Preferably, a GGSN multicast identifier is used to encapsulate said M-PDU 

and forward it to the or each responsible second node (SGSN), and each multicast 
logical link is associated with one of said records. Thus, each multicast group has an 
identifier and logical link at the packet radio layer (or GTP layer in the case of 
UMTS). The GGSN multicast identifier may be set arbitrarily so long as the 

20 receiving node is able to resolve different multicast logical links on the basis thereof 
In one embodiment, the GGSN identifier is set by the receiving endpoint of the 
multicast logical link i.e. the SGSN for the Gn interface. 

In one embodiment, said GGSN multicast identifier comprises a first 
25 Mukicast-Tunnel Endpoint Identifier (M-TEID) calculated from the multicast address 
of the M-PDU, and said record is a multicast PDP (M-PDP) context. The first M- 
TEID may be set equal to the IP multicast address in IPv4. For IPv6 multicast 
addresses that are 128-bits long and are therefore too big to be held in the first M- 
TEID field, the first M-TEID may be set arbitrarily by the SGSN. This may be done, 
30 for example, with a hashing function that hashes the 1 28-bit field to a size that fits the 
first M-TEID field. 

Advantageously, the method further comprises the steps, upon receipt of said 
M-PDU the or each second node (SGSN), of searching a database for records of 
35 multicast logical links maintained by the second node (SGSN) with the first node 



(GGSN) for a record associated with said M-PDU. 

Preferably, said search is performed using the GGSN multicast identifier (or 
first M-TEID) associated with the M-PDU. 

Advantageously, each record contains a list of multicast subscriber entries for 
a particular multicast group, each multicast subscriber entry containing a reference to 
a second active logical link associated with the subscriber mobile node of that entry, 
and wherein said reference is used to look up the second active logical link for each 
multicast subscriber entry and extract the identity of the responsible third node 
(RNC), and to look up a mobility management record for the subscriber mobile node. 

Preferably, said reference comprises a Transaction Identifier (TI) and/or 
International Mobile Subscriber Identity (IMSI) of the subscriber mobile node, and 
said second active logical link comprises the PDP context associated with said 
subscriber mobile node between the second node (SGSN) and the responsible third 
node (RNC). 

Advantageously, the method further comprises the step of establishing a 
connection in the packet switched domain if the mobility management record 
indicates that the subscriber mobile node is not connected in that domain. 

Preferably, the method further comprises the steps of creating a list containing 
the identity of the or each third node (RNC) responsible for said at least one 
subscriber mobile node, removing duplicate identities from said list and replicating 
and forwarding said M-PDU to the or each RNC remaining on the list. 

Advantageously, an SGSN multicast identifier is used to encapsulate said M- 
PDU and forward it to the or each responsible third node (RNC), and the or each 
multicast logical link is associated with said record. The SGSN multicast identifier 
may be set arbitrarily so long as the receiving node is able to resolve different 
multicast logical links on the basis thereof. In one embodiment, the SGSN identifier 
is set by the receiving endpoint of the multicast logical link i.e. the RNC for the lu 
interface. 
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Preferably, said SGSN multicast identifier comprises a second Multicast- 
Tunnel Endpoint Identifier (second M-TEID) calculated from the multicast address of 
the M-PDU, and said record is a multicast PDP (M-PDP) context. The second M- 
TEID may be set equal to the IP multicast address in IPv4. For IPv6 multicast 
5 addresses that are 128-bits long and are therefore too big to be held in the second M- 
TEID field, the second M-TEID may be set arbitrarily by the RNC. This may be 
done, for example, with a hashing function that hashes the 128-bit field to a size that 
fits the second M-TEID field. 

10 Advantageously, the method further comprises the steps, upon receipt of said 

M-PDU the or each third node (RNC), of searching a database for records of 
multicast logical links maintained by the third node (RNC) with the second node 
(SGSN) for a record associated with said M-PDU. 

15 Preferably, said search is performed using the SGSN multicast identifier (or 

second M-TEID) associated with the M-PDU. 

Advantageously, each record contains a list of multicast subscriber entries for 
a particular multicast group, each multicast subscriber entry containing a reference to 
20 a third active logical link associated with the subscriber mobile node of that entry, 
and wherein said reference is used to look up the third active logical link for each 
multicast subscriber entry and extract the identity thereof 

In one embodiment said reference comprises a radio access bearer (RAB) ID 
25 and/or IMSI and said third active logical link is an RAB context, the method further 
comprising the steps of replicating said M-PDU and forwarding to said subscriber 
mobile node over the wireless link. 

In another embodiment the individual PDP and RAB contexts that are used 
30 for multicast message forwarding maintain an additional field storing an identifier of 
the M-PDP or M-RAB context they are associated with. 

According to another aspect of the present invention there is provided a 
network node for use in a packet radio network, which network node comprises 
35 means for storing and executing computer executable instructions for performing a 
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method or part of a method as set out above. The network node may be a GGSN, 
SGSN, RNC or any hierarchical equivalents. 

According to another aspect of the present invention there is provided a 
5 network node for use in a packet radio network, which network node comprises 
means for storing and executing computer executable instructions for performing 
either: 

(1) any of the first node (GGSN) method steps as set out above; or 

(2) any of the second node (SGSN) method steps as set out above; or 
10 (3) any of the third node (RNC) method steps as set out above. 

According to another aspect of the present invention there is provided a 
computer program comprising computer executable instructions for causing a 
computer to perform the first node (GGSN) method steps as set out above; second 
15 node (SGSN) method steps as set out above; and/or any of the third node (RNC) 
method steps as set out above. 

The computer program may be embodied on a record medium, stored in a 
computer memory, embodied in a read-only memory or carried on an electrical 
20 carrier signal. The program or any part thereof may be downloaded from one node, 
external or internal to the packet radio network, to one or more of the nodes on the 
UMTS network. This is advantageous as no hardware changes need to be made to 
any of the UMTS network nodes. 

25 Multicast Group Management 

The present invention includes a method of multicast group management for a 
packet radio network, and more particularly but not exclusively a UMTS network. 
Preferred embodiments of the present invention employ new multicast routing 
30 procedures at the packet radio layer or PDP layer that lies above the U DP/IP layer in 
the packet radio network. Thus nodes in the packet radio network do not need to use 
IGMP, MLD or any other IP multicast group management protocols in order to 
handle multicast traffic arriving from external packet data networks. 



35 



According to another aspect of the present invention there is provided, in a 
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packet radio network comprising a radio access network (RAN) and a core network 
(CN) via which a plurality of mobile nodes may communicate over a wireless link 
with an external packet data network, a method of administering at least one 
multicast group, subscribers of which are from said plurality of mobile nodes, which 
5 method comprises the steps of: 

(1) maintaining a first database of subscribers of each multicast group at a 
first node (GGSN) in said packet radio network, said database enabling identification 
of the or each second node (SGSN), or any other network node on the packet radio 
network, responsible for the subscribers of each multicast group; 

10 (2) providing a mapping between subscribers of each multicast group and 

a number of multicast logical links between the first node (GGSN) and the or each 
second node (SGSN); 

wherein, where there is more than one subscriber of a multicast group served 
by a second node (SGSN), the first database maps those subscribers to a number of 

15 multicast logical links that is less than the number of those subscribers. In this way 
the number of times a multicast packet needs to be sent over a packet radio network 
can be reduced as subscribers in each group are managed and associated with only 
one or a small number of dedicated multicast logical links. The mapping of the 
subscribers of a multicast group to a number of multicast logical links may be 

20 provided by associating the IP address of the multicast group with the number of 
multicast logical links for example. The multicast logical links may be the M-PDP 
contexts and/or M-RAB contexts defined herein. 

In one embodiment, for each multicast group, said database maps subscribers 
25 thereof to a single multicast logical link per second serving node (SGSN). 

Preferably, identification of the or each second node (SGSN) is by means of a 
pointer for each subscriber in said database, each pointer referencing an individual 
logical link for a subscriber. 

30 

In one embodiment each individual logical link is a PDP context that 
identifies the second node (SCjSN) serving that subscriber. 

Advantageously, said multicast logical link is at the PDP layer of the packet 
35 data network. By managing subscribers of multicast groups at the packet radio layer. 



e.g. the GTP layer that is above the UDP/IP layer in the packet radio network, nodes 
do not need to implement specific group management protocols designed for the 
network layer. Thus they are able to use the existing infrastructure, reducing the 
processing overhead on the network. 

Preferably, the method further comprises the steps of: 

(1) maintaining a second database of subscribers of each multicast group 
at the second node (SGSN) in said packet radio network, said database enabling 
identification of one or more third nodes (RNC) responsible for the subscribers of 
each multicast group; 

(2) providing a mapping between subscribers of each multicast group and 
a number of multicast logical links between the second node (SGSN) and the or each 
third node (RNC); 

wherein, where there is more than one subscriber of a multicast group served 
by a second node (SGSN), the second database maps those subscribers to a number 
of multicast logical links that is less than the number of those subscribers. The 
mapping of subscribers of a multicast group and a number of multicast logical links 
may be by associating a first multicast identifier (first M-TEID) with those links. The 
first multicast identifier may be configured by the second node (SGSN) during set up 
of the multicast logical links for that group. The second node (SGSN) may inform the 
first node (GGSN) of the first multicast identifier that it should use in forwarding 
multicast packets that it receives. 

Advantageously, the method further comprises the steps of maintaining a 
third database of subscribers of each multicast group at a third node (RNC) in said 
packet radio network, said third database enabling identification of the or each fourth 
node (Node B), or any other network node on the packet radio network, responsible 
for the subscribers of each multicast group; 

wherein said third node duplicates multicast data packets according to the 
number of users served by the or each fourth node (Node B) and forwards them on to 
a radio access bearer for transmission over a wireless link. 

Preferably, if a user of a mobile node wishes to subscribe to a multicast 
group, the mobile node sends a join request message over its individual logical link to 
the packet radio network so as to cause the first, second and/or third nodes to add that 
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mobile node to their databases such that multicast packets arriving subsequently at 
the first node (GGSN) are forwarded to said mobile node over said number of 
multicast logical links to its serving second node (SGSN). 

5 In one embodiment said join request message is sent firstly to the mobile 

node's serving node (SGSN) in the packet radio network. 

Advantageously, wherein if said first, second and/or third node does not 
include an entry for the multicast group that the mobile node wishes to join, the 

10 method further comprises the steps of establishing a multicast logical link between 
the core network (CN) and the radio access network (RAN), and causing multicast 
messages to be forwarded from the external packet data network to the first node 
(GGSN) of the packet radio network. If a multicast logical link needs to be created, 
the network may also configure and/or assign a first and/or second multicast 

15 identifier (first M-TEID and second M-TEID) to the multicast logical link and then 
inform the other nodes of the first identifier. The configuring may be done by the 
SGSN and/or RNC for the Gn (first M-TEID) and lu (second M-TEID) interfaces 
respectively. 

20 Preferably, the step of establishing a mulricast logical link comprises the steps 

of: 

(1) creating a multicast logical link entry in a database at the second node 
(SGSN) of the mobile node and adding details of the mobile node thereto; 

(2) informing the first node (GGSN) and/or a third node (RNC) of the 
25 multicast logical link; 

(3) determining whether or not at said first node (GGSN) and/or third 
node (RNC) there is an existing multicast logical link entry for that multicast group; 
and 

(4) if necessary creating a multicast logical link entry at the first node 
30 (GGSN) and/or third node (RNC), thereby establishing a multicast logical link 

between the first node (GGSN) and the third node (RNC). The second node (SGSN) 
may also configure and store in memory the first multicast identifier for the Gn 
interface at this stage and forward it to the first node (GGSN) such that it can then 
identify incoming M-PDUs from the first node (GGSN). The third node may also 
35 configure and store a second multicast identifier for the lu interface at this stage and 



forward it to the second node (SGSN) such that it can then identify incoming M- 
PDUs from the first node (SGSN). 

Advantageously, if a user of a mobile node wishes to leave a multicast group, 
the mobile node sends a leave request message over said individual logical link so as 
to cause said first, second and/or third node to remove the mobile node from their 
databases for that multicast group. 

In one embodiment said leave request message is sent firstly to the mobile 
node's serving node (SGSN). 

Preferably the method further comprises the step of tearing down the or each 
multicast logical link between the CN and RAN upon receipt of said leave request 
message if said mobile node is the last subscriber in the group. 

Advantageously, the method further comprises the step upon receipt of a 
deactivation message for a mobile node's individual logical link, of ascertaining 
whether or not that mobile node is a subscriber of any multicast groups, and if so, 
removing that mobile node from the or each multicast logical link of which it is a 
subscriber. 

Preferably, said deactivation message is firstly sent to the mobile node's 
serving node, the method further comprising the steps of sending a message to the 
first node (GGSN) to cause removal of a record of the mobile node's individual 
logical link, and the first node (GGSN) performing the steps set out above to remove 
the mobile node from the or each multicast logical link of which it is a subscriber. 

Advantageously, said deactivation message is firstly sent to the mobile node's 
serving node, the method further comprising the steps of sending a message to the 
third node (RNC) to cause removal of a record of the mobile node's individual 
logical link, and the third node (RNC) performing the steps set out above to remove 
the mobile node from the or each multicast logical link of which it is a subscriber. 

Preferably, said packet radio network is a Universal Mobile 
Telecommunications System (UMTS), said first node is a gateway GPRS support 



node (GGSN), said second node is a serving GPRS support node (SGSN), said third 
node is a third node (RNC), and said fourth node is a base station (Node B). 

According to another aspect of the present invention there is provided a 
network node for use in a packet radio network, which network node comprises 
means for storing and executing computer executable instructions for performing a 
method or part of a method as claimed in any preceding claim. The network node 
may be a router that is a GGSN, SGSN or RNC, or any hierarchical equivalents. 

According to another aspect of the present invention there is provided a 
network node for use in a packet radio network, which network node comprises 
means for storing and executing computer executable instructions for performing 
either: 

( 1 ) any of the first node method steps as set out above; 

(2) any of the second node method steps as set out above; or 

(3) any of the third node method steps as set out above. 

A computer program comprising computer executable instructions for causing 
a computer network node to perform either: 

(1) any of the first node method steps as set out above; 

(2) any of the second node method steps as set out above; 
(3 ) any of the third node method steps as set out above; or 

(4) any combination of (1) to (3). 

The computer program may be embodied on a record medium, stored in a 
computer memory, embodied in a read-only memory or carried on an electrical 
carrier signal. The program or any part thereof may be downloaded from one node, 
external or internal to the packet radio network, to one or more of the nodes on the 
UMTS network. This is advantageous as no hardware changes need to be made to 
any of the UMTS network nodes. 

It will be apparent that both the routing aspects of the invention as set out 
above and the group management aspects of the invention as set out above can be 
combined to provide an overall method. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

For a better understanding of how the invention may be put into practice, a 
preferred embodiment of the invention applied to a UMTS network will be described, 
5 by way of example only, with reference to the accompanying drawings, in which: 

Fig. 1 is a schematic representation of IMT-2000 UMTS architecture and its 
connection to external packet data networks (PDNs); 

Fig. 2 is a schematic representation of the protocol stacks in the user plane of 
the UMTS network of Fig. 1; 
10 Fig. 3 is a block diagram of a gateway GPRS support node (GGSN) or 

serving GPRS support node (SGNS) of the UM I S network of Fig. 1 in accordance 
with the present invention; 

Fig. 4 is a block diagram of a radio network controller (RNC) of the UMTS 
network of Fig. 1 ; 

15 Fig. 5 is a flowchart of the steps of a set of computer executable instructions 

stored and performed by the GGSN of Fig. 1 ; 

Fig. 6 is a flowchart of the steps of a set of computer executable instructions 
stored and performed by the SGSN of Fig. 1 ; 

Fig. 7 is a flowchart of the steps of a set of computer executable instructions 
20 stored and performed by the RNC of Fig. 1 ; 

Fig. 8 is a comparison of the multicast routing method of the present 
invention against standard UMTS routing based on tunnels; 

Fig. 9a is a schematic representation of encapsulation of an IGMP message 
within an IP datagram; 

25 Fig. 9b is a schematic representation of the format of the fields in an IGMP 

message; 

Fig. 10 is a schematic representation of the signalling procedure for a 
multicast group join procedure in accordance with the present invention in the UMTS 
network of Fig. 1 ; 

30 Fig. 11 is a schematic representation of the signalling procedure for a 

multicast group leave procedure in accordance with the present invention in the 
UMTS network of Fig. 1; and 

Fig. 12 is a schematic representation of the signalling procedure for an 
implicit multicast group leave procedure in accordance with the present invention on 

35 the UMTS network of Fig. 1 . 
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The specification is set out in two sections: section 1 describes a multicast 
routing protocol and section 2 describes a multicast group management protocol, 
both for UMTS networks. 

(1) Muhicast Routimi In UMTS 

Referring to Fig. 1 a UMTS network generally identified by reference 
numeral 1 comprises of several network nodes defined at the logical level and a 
corresponding number of interfaces between the nodes. The UMTS network 1 is 
divided into (a) the Core Network (CN) 2 consisting of the gateway GPRS support 
node (GGSN) 3 and the serving GPRS support node (SGSN) 4, and (b) the UMTS 
Terrestrial Radio Access Network (UTRAN) 5 consisting of the radio network 
controller (RNC) 6 and Node B 7. The GSNs (i.e. the GGSN and SGSN) constitute 
the backbone of the UMTS network 1, A brief description of the functionality of the 
network nodes shown in Fig. 1 relevant to the invention is given as follows: 

(1) Gateway GPRS Support Node (GGSN) 3: the GGSN 3 is used as an interface 
to external Packet Data Networks (PDNs) 8. The PDN 8 may be the Internet or a 
wide area network (WAN) for example. The GGSN 3 maintains routing information 
required to tunnel user data packets to the SGSN 4 serving a particular subscriber. 
Other functions include network and subscriber screening and address mapping. 

(2) Serving GPRS Support Node (SGSN) 4: the SGSN 4 delivers packets to 
subscribers within its service area. The SGSN 4 detects new mobile stations within a 
given service area, processes registrations of new mobile subscribers and keeps 
record of their location inside a given service area. 

(3) Radio Network Controller (RNC) 6: the RNC 6 is the network element 
responsible for the control of the radio resources within the UMTS Terrestrial Radio 
Access Network (UTRAN) 5. The RNC 6 is responsible for load and congestion 
control of its own cells. 

(4) Node B 7: the main function of the Node B 7 is to perform the air interface 
processing (channel coding and interleaving, rate adaptation, spreading, etc.). It also 
performs some Radio Resource Management. It logically corresponds to the GSM 
Base Station. 

In UMTS, every Node B is connected to an RNC through the lub interface 9. 
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Every RNC is connected to an SGSN through the lu interface 10. Finally, every 
SGSN is connected to a GGSN through the Gn interface II. Mobile stations or 
handsets combined with the User Subscriber Identity Module (USIM) are referred to 
by the term User Equipment (UE) 12. "Mobile Station (MS)", a term used in the 
5 context of GSM and GPRS networks, is equivalent to the UE 12. 



Further details of UMTS networks can be found in Third Generation 
Partnership Project, Technical Specification 23.060 v5.2.0. General Packet Radio 
Service (GPRS); Service Description; Stage 2, Release 5, June 2002 hereinafter 
10 "3GPPTS"). 



In describing point-to-point or unicast packet routing for UMTS, two 
mechanisms are of central importance: the Packet Data Protocol (PDP) and the GPRS 
Tunnelling Protocol (GTP). PDP is the generic name for packet data transfer during 

15 an active session (see H. Kaaranen et uL "UMTS Networks" John Wiley and Sons, 
2001). Before the UE 12 can exchange data with a host on the external PDN 8, the 
UE 12 must first establish a virtual connection with the UMTS network 1. This is 
similar to a dial-up connection established through the Public Switched Telephone 
Network (PSTN) in order to access a particular Internet Service Provider (ISP). In 

20 UMTS, virtual connections created and maintained within the network are referred to 
as "PDP contexts". The PDP context provides information to support packet delivery 
between the UE 12 and the UMTS network 1 and contains all parameters describing 
the packet data connection by means of end-point addresses and QoS. 7 he PDP 
contexts are maintained in the UE 12, SGSN 4 and GGSN 3. A single UE may have 

25 several PDP contexts associated with it. The information contained within the PDP 
contexts is dynamic and changes as a resuh of user mobility. 

The GGSN 3, SGSN 4 and the UE 12 maintain PDP contexts that list 
different items of information relevant to routing user data packets through the 
30 UMTS network 1 . The following is a partial list of this information: 

(a) PDP context identifier (used for indexing the list of stored PDP 
contexts); 

(b) PDP type (either X.25, PPP or IP); 

(c) PDP address (e.g. an IPv4 address); 

35 (d) Access Point Name (APN), which is a logical name for an external 
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network and/or service that the subscriber wishes to connect to; and 

(e) QoS information, such as the subscribed, requested and negotiated 
QoS profiles. 

The GGSN 3 maintains activated PDP contexts consisting of routing 
information that allows the GGSN 3 to forward downlink user data packets to the 
serving SGSN 4. The SGSN 4 maintains activated PDP contexts consisting of routing 
information that enables the SGSN to forward user data packets either to the GGSN 3 
in the uplink direction or to the serving RNC 6 in the downlink direction. 

Instead of storing PDP contexts, the RNC 6 stores "Radio Access Bearer 
(RAB) contexts", which are roughly equivalently to the PDP contexts in that the 
RAB contexts allow the RNC 6 to receive user data packets from the SGSN 4 in the 
downlink direction and to forward packets to the serving SGSN 4 in the uplink 
direction. 

GTP is a protocol that controls communication across the Gn 1 1 , Gp and lu 
interfaces. GTP essentially tunnels multi-protocol (e.g. IP, UDP) packets through the 
UMTS backbone. GTP consists of two sub-protocols: GTP-C is used for control 
signalling between the GGSN 3 and SGSN 4, whereas GTP-U is deployed in the 
user-plane from the GGSN 3 across the lu interface to the serving RNC 6 in the 
UTRAN 5. On all interfaces GTP-U operates on top of the UDP/IP protocol family 
(see Fig. 2). GTP-U allows multi-protocol user data to be tunnelled across the 
respective interfaces. UMTS network elements and protocols transferring user data 
packets between UTRAN 5 and the GGSN 3 need not be aware of different 
addressing mechanisms at the IP (network) layer in order to be able to associate user 
data packets to specific PDP contexts. In encapsulating user data packets, GTP-U 
adds a GTP protocol header containing tunnelling information into every user data 
packet. The tunnelling information includes a 32-bit Tunnel Endpoint Identifier 
(TEID). The TEID is used to identify a PDP context (or in the lu case a RAB 
context) inside a tunnel endpoint. The TEID is a unique identifier within one IP 
address of an RNC 6, SGSN 4 or GGSN 3 network node and has meaning only 
within the GTP protocol. The Network-layer Service Access Point (NSAPI) and 
International Mobile Subscriber Identity (IMSI) are used for network-layer routing. 
In communication with the RNC 6 across the lu and Uu interfaces, the RAB ID is 
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used to identify the radio access bearer and that information element is set to be 
identical to the NSAPI value. For the user plane, i.e. for GTP-U, each PDP context 
has a one-to-one relationship between the TEID on one hand, and NSAPI and IMSI 
on the other hand; or in the lu reference point case, between TEID and RAB ID and 
IMSI. However, the algorithm for computing the value of the TEID is 
implementation dependant (see 3GPPTS). 

GTP-U tunnelling terminates at the RNC 6 within the UTRAN 5. Since 
GTP-C is only deployed over the Gn interface, the Radio Access Network 
Application Part (RANAP) protocol is used for establishing GTP-U tunnels between 
the SGSN 4 and the RNC 6. 

In the context of UMTS routing, packets are usually referred to as PDP 
Packet Data Units (PDUs). Furthermore, PDP PDUs are routed as Network PDUs 
(N-PDUs) between the UE and the GGSN. 

A brief overview of the GTP-based tunnelling procedure for mobile- 
terminated packet transfers between the GGSN 3 and RNC 6 is given below: 

(1) Having received a PDP PDU, the GGSN 3 attempts to correlate the 
received PDU with any of the entries within its list of PDP contexts. When multiple 
PDP contexts exist for the same PDP address of a UE 12, the GGSN 3 routes 
downlink PDUs to the different GTP tunnels based on the Traffic Flow Template 
(TFT) assigned to PDP contexts (see 3GPPTS). 

(2) Having successfully identified the correct PDP context, the GGSN 3 
then encapsulates the N-PDU with a GTP header (using the TEID given in the PDP 
context) and forwards the N-PDU to the SGSN 4 using the IP address of the SGSN 4 
as specified by the PDP context. 

(3) Once the SGSN 4 receives a N-PDU from the GGSN 3, the SGSN 4 is 
able to resolve the exact PDP context by correlating the 1 EID given in the GTP 
header with the TEID stored within its list of PDP contexts. 

(4) Having identified the appropriate PDP context for the N-PDU (and 
assuming that the addressed subscriber is in the Packet Mobility Management 
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(PMM)-CONNECTED state), the SGSN 4 encapsulates and forwards the N-PDU to 
the appropriate serving RNC 6. 

The UE 12 activates a PDP context by sending an Activate PDP Context 
Request message to the SGSN 4. The SGSN 4 validates the Activate PDP Context 
Request using the information provided by the UE and the PDP context subscription 
records. The SGSN 4 then sends a Create PDP Context Request message to the 
serving affected GGSN 3. The GGSN 3 creates a new entry in its PDP context table. 
The new entry allows the GGSN 3 to route PDP Packet Data Units (PDUs) between 
the SGSN 4 and the packet data network. The GGSN 3 then returns a Create PDP 
Context Response message to the SGSN 4. In lu mode. Radio Access Bearer (RAB) 
setup is done by the RAB Assignment procedure. For each PDP Address a different 
quality of service (QoS) profile may be requested. 

A PDP context establishes a mapping between a single subscriber and a 
generic PDP address (e.g. an IP address). A PDP context does not contain any 
references to external networks (e.g. addresses of web or email servers located 
outside of the UMTS network) or address identifiers for specific services that may be 
accessed by the subscriber while using a given PDP address. This is suitable for 
unicast connections since the majority of such connections require the subscriber to 
trigger the start of a session (e.g. web browsing or email). Multicast applications such 
as IP multicast on the other hand require an explicit mapping between the address 
identifier(s) of the subscriber(s) and an identifier of the multicast group that the 
subscriber(s) would like to join. 

In considering one-to-many communications where a source wishes to 
distribute identical messages to m different subscribers within the UMTS network 1, 
the drawback of the UMTS routing procedures based on unicast tunnelling across the 
Gn and lu interfaces becomes apparent. Since each tunnel is established for a single 
subscriber and an associated network access point identifier (i.e. the NSAPI), every 
PDU addressed to the multicast group will be transmitted n times between the GGSN 
3 and SGSN 4 where n is the number of multicast subscribers that are located in the 
service area of the SGSN 4. The same applies over the lu interface: every multicast 
PDU will be forwarded p times between an SGSN 4 and an RNC 6 where p 
represents the number of multicast subscribers within the service area of the RNC 6. 
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When considering all SGSNs and RNCs in the network the M-PDU will be sent m 
times in total. This clearly is wasteful of network bandwidth. 

In order to support multicast connections in UMTS networks, a "multicast 
PDP (M-PDP) context" is introduced that establishes a mapping between the address 
of a multicast group and a sub-set of members of that group that are currently being 
served by a particular network node. M-PDP contexts are stored at the GGSN 3 and 
SGSN 4 to maintain routing parameters for distributing multicast messages within the 
network, as well as quality of service (QoS) characteristics that apply to members of 
the multicast group. M-PDP contexts store the identities of multicast subscribers 
within the service area of a given network node. An M-PDP context at a GGSN 3 
network node comprises following fields: 

- M-PDP context identifier 

- M-PDP type used in external networks (e.g. IP multicast) 

- M-PDP address used in external networks (e.g. 238.255.254.1) 

- Muhicast TEID (M-TEID) for the Gn interface 

- QoS profiles 

- One or more multicast subscriber records. Each multicast subscriber record 
encapsulates a reference to an activated PDP context. 

An M-PDP context at the SGSN network node 4 comprises following fields: 

- M-PDP context identifier 

- M-PDP type used in external networks (e.g. IP multicast) 

- M-PDP address used in external networks (e.g. 238.255.254.1) 

- M-TEID for the Gn interface 

- M-TEID for the lu interface 

- QoS profiles 

- One or more multicast subscriber records. Each multicast subscriber record 
encapsulates a reference to a mobility management (MM) and activated PDP context. 

The RNC network node 6 does not maintain PDP contexts. Instead it stores 
RNC Radio Access Bearer (RAB) contexts that allow the node to resolve the 
subscriber that is associated with a GTP-encapsulated N-PDU received from an 
SGSN 4. In analogy to M-PDP contexts, multicast group membership at the RNC is 
managed by means of '^multicast RAB (M-RAB)" contexts that store references to 
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the actual RNC RAB contexts maintained at the RNC node 6. A RNC M-RAB 
context stores following entries: 

- M-PDP context identifier 

- M-PDP type used in external networks (e.g. IP multicast) 

- M-PDP address used by external networks (e.g. 238.255.254.1) 

- M-TEID for the lu interface 

- QoS profiles 

- One more multicast subscriber records. Each multicast subscriber record 
encapsulates a reference to an RNC and activated RNC RAB context. 

An M-RAB groups together several RABs and as such is not a true RAB in 
itself. Both M-PDP and M-RAB contexts store all pertinent details (multicast 
protocol, multicast address and QoS parameters) that are valid for a single multicast 
group. Several M-PDP and M-RAB contexts with the same M-PDP type, address and 
QoS profiles but different multicast subscription records are maintained at different 
GSN and RNC network nodes throughout the UMTS network. Therefore each 
M-PDP or M-RAB context stored at a particular GSN or RNC node contains a sub- 
set of the multicast subscribers that are present within the network. A single M-PDP 
or M-RAB context maintains multicast records for all multicast subscribers located 
within the service area of the network node. Each GSN or RNC network node may 
store one or more M-PDP or M-RAB contexts for each multicast group serviced 
within the location area of the network node. All M-PDP contexts with the same 
M-PDP address share the same M-TEID for either the Gn or lu interfaces. Hence, all 
multicast messages within a group are tunnelled with the same M-TEID using OTP 
over either the Gn or lu interface. This is in contrast to conventional TEIDs that 
tunnel user data for individual users only. A single multicast message is sent exactly 
once between any two network nodes over the Gn and lu interfaces using the 
M-TEID for the group independent of how many multicast subscribers are within the 
service area of the receiving network node. A single network node such as the GGSN 
3 must replicate the multicast message in order to forward it over the Gn interface to 
all SGSN network nodes that are servicing multicast subscribers for the group. The 
same applies to multicast message forwarding over the lu interface between SGSN 4 
and RNC 6 network nodes. 

Every M-PDP or M-RAB context maintains a multicast subscriber record for 
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each multicast subscriber (i.e. user subscribing to the multicast group) within the 
service area of the particular network node. A multicast subscriber record 
encapsulates a reference to the relevant routing, mobility management or radio access 
bearer details for that particular multicast subscriber. The entries within a multicast 
subscriber record allow the GGSN 3 to extract the PDP context, the SGSN 4 to 
extract the MM and PDP contexts and the RNC 6 to extract the RNC and RAB 
contexts of a particular multicast subscriber. Maintaining references to the routing, 
mobility, radio network control and radio access bearer records and not the actual 
records themselves has the advantage that the location update procedures performed 
by the network remain largely unchanged. In order to accommodate location update 
and handover procedures, the PDP contexts that are referenced by multicast 
subscriber records must contain a reference to the M-PDP context they are associated 
with. The same applies to the M-RAB contexts in that the RAB contexts must contain 
a reference to any associated M-RAB contexts. The PDP and RAB contexts that are 
used for multicast message forwarding therefore maintain an additional field storing 
the identifier of the M-PDP or M-RAB context they are associated with. 

A multicast subscriber record within an M-PDP context consists of following 

fields: 

- International Mobile Subscriber Identity (IMSI) 

- Transaction Identifier (TI) of PDP context to be referenced for extracting multicast 
subscriber routing details. 

- NSAPI of PDP context to be referenced for extracting muhicast subscriber routing 
details. 

- TEID of PDP context to be referenced for extracting multicast subscriber routing 
details. 

A multicast subscriber record within an RNC M-RAB context stores 
following fields: 
-IMSI 

- RAB ID 

Based on the fields encapsulated within the multicast subscriber records 
within an M-PDP or RNC M-RAB context, the GGSN 3, SGSN 4 and RNC 6 are 
able to perform a look-up of the PDP, MM, RNC and RAB contexts that hold the 
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routing, mobility management, radio network control and radio access bearer 
information for multicast subscribers. 

The multicast routing procedure based on M-PDP and RNC M-RAB contexts 
only considers the downlink direction between the GGSN 3 and the RNC 6. The 
connection between the RNC 6 and the Node B 7 depends on the air interface and is 
therefore largely dependant on radio resource management. All uplink traffic is 
routed based on conventional UMTS routing procedures and is therefore transparent 
to the multicast routing scheme. Due to this only the GGSN 3 and SGSN 4 must 
forward downstream multicast messages, whereas the RNC 6 must only resolve the 
multicast GTP tunnels in order to extract the RNC and RNC RAB contexts of the 
subscribers being served by the RNC node. The RNC 6 then replicates the data in the 
multicast packet for transmission over the air interface to each multicast subscriber. 

M-PDP contexts have respective M-TEIDs for the Gn and lu interfaces (first 
and second M-TElDs). The GTP protocol tunnels all multicast messages using the 
M-TEIDs given by the M-PDP context for that multicast group. The multicast tunnels 
are established using the signalling protocol GTP-C between the GGSN 3 and SGSN 
4 and the signalling protocol RANAP between the SGSN 4 and RNC 6. The 
algorithm for computing the M-TEID is implementation-specific. Due to an 
anticipated inter-operation of the proposed UMTS multicast scheme with IPv4 
multicast, the M-TEID may be readily set equal to the 32-bit class D multicast 
address of the IPv4 multicast group. The M-TEID of the M-PDP context is always 
used for multicast message forwarding and overrides the TEID stored in the PDP 
contexts referenced by individual multicast subscriber records. 

Fig. 3 shows the GGSN 3 in more detail that comprises a case 21 having 
network interface ports 22 and 23 to which respective cables 24 and 25 provide a 
physical link to IP network 8 and the UMTS network 1. Two network interface cards 
26 and 27 are connected to their respective network interface ports 22 and 23. A 
hardware packet switch 28 connects the network interface cards 26, 27 and a central 
processing unit (CPU) 29 can communicate with a routing table 30 and router 
management tables 3 1 . 

Each network interface card 26, 27 comprises a link layer protocol controller 
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32 that has access to an interface management table 33 and a hardware address table 
34 (e.g. Address Resolution Protocol cache). In communication with the link protocol 
controller 32 is a network protocol-forwarding engine 35 having access to a 
forwarding table 36 (route cache), and an interface queue manager 37. Both the 
network protocol forwarding engine 35 and interface queue manager 37 have an 
interface to and from the packet switch 28 respectively. 

In use, frames are received by the link layer protocol controller 32 that 
handles the link layer protocol (e.g. HDLC, Ethernet) used over the physical link. 
Frame integrity is checked and valid frames are converted into packets by removing 
the link layer header and, if necessary, the packets are queued in a queue 38. Storage 
capacity is often in the form of a ring of memory buffers. One packet at a time is 
removed from the queue 38 by the network protocol-forwarding engine 35 and the 
forwarding table 36 determines whether or not the packet requires detailed 
examination by the CPU 29. Via the CPU 29 the SGSN to which the packet should 
be sent obtained from the PDP context associated with the IP address of the UE that 
the packet is destined. Once the destination IP address of the SGSN is found the CPU 
searches the ARP cache for a Media Access Control (MAC) address for the 
destination. A OTP header is added to the datagram that contains the TEID of the 
PDP context. The datagram (including OTP header) is then encapsulated in an IP 
packet header with a destination address of the SGSN. The CPU 29 now knows 
where to send the packet and the new link layer header to use. The link layer address 
is added and the packet is linked into the list of frames to be sent on from the 
appropriate network interface card. The packet is then forwarded to the packet switch 
28 and onto the network interface card where the packet joins a queue 39 to be 
processed by the interface queue manager 37. From here the packet joins one of a 
number of link output queues 40 until the link layer protocol controller 32 can 
process it. The link layer protocol controller 32 encapsulates the packet in a link layer 
header that includes the Media Access Control (MAC) address of the SGSN to which 
the packet is to be sent. The MAC address is obtained from the hardware address 
table 34. The packet is then placed on the physical channel by the link layer protocol 
controller 32. 

Various types of GPRS support node are available and the present invention 
is not limited to that described above. Further examples are available from Cisco 
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Systems, Inc. ( www.cisco.com V Siemens AG ( www.siemens.com ) and Alcatel 
( www.alcatel.cQm ) for example. 

In addition the CPU 29 of the GGSN 3 has access to a memory 40. The 
memory 40 stores the computer executable instructions that must be performed and 
the context database that must be created and maintained by the GGSN 3 in 
performing the muUicast routing and administration described below. In particular, 
the memory 40 stores the PDP context and M-PDP contexts of subscribers. 

The SGSN 4 is similar in construction and operation to the GGSN 3. 
However, in addition to the PDP and M-PDP contexts, the memory in the SGSN 4 
stores a context database that contains all mobility management (MM) contexts for 
the subscribers within its service area. 

Fig. 4 shows part of the RNC 6 in more detail that comprises a receiver 41, a 
control unit 42 (e.g. CPU), a transmitter 43 and a memory 44. In use the receiver 41 
receives N-PDUs from the SGSN 4 and Node B 7. As will be described in greater 
detail below the control unit 42 of the RNC 6 is able to reference various M-RAB 
contexts held in the memory 44 of the RNC 6. 

In the following section a detailed description of multicast message 
forwarding based on M-PDP and RNC M-RAB contexts at the GGSN 3, SGSN 4 and 
RNC 6 is given. 

The GGSN 3 interfaces with external PDNs, such as the Internet, and is the 
entry point to the UMTS network 1 for all traffic originating from external sources. 
Multicast traffic may originate from outside of the UMTS network 1 as well as from 
within the network. It is assumed that muhicast traffic originating from within the 
network interfaces with the GGSN in the same fashion as multicast traffic originating 
from external PDNs. 

Referring to Fig. 5 the first step S 1 in performing multicast routing based on 
M-PDP contexts is for the GGSN 3 to identify the M-PDP context that corresponds 
to a multicast message that it has received. This is done by evaluating each PDP and 
M-PDP context stored at the GGSN until the matching record is found. Depending on 



whether the multicast protocol being used allows the network to distinguish unicast 
from multicast messages (e.g. based on the address), the matching process may be 
optimised by only searching for a matching M-PDP context and bypassing the list of 
stored PDP contexts if the received message is a multicast message. This 
optimisation may be applied in the case of TP multicast since unicast messages are 
easily distinguished from multicast messages by simple inspection of the IP address. 
In this case the GGSN will search for the M-PDP context that contains the multicast 
address of the packet it has received. If there is no match at step S2, the GGSN 3 
silently discards the received multicast packet at step S3. 

If there is match a step S2, the GGSN 3 begins iterating through the multicast 
subscriber records of the M-PDP context at step S4 and extracts the NSAPI, TEID 
and IMSI fields from each record. At step S5 these fields are used in order to perform 
a look-up of the appropriate PDP context in use by the multicast subscriber. It is 
possible to just use the NSAPI and TEID to do this. However, by also using the IMSI 
greater reliability of searching is obtained. Should the NSAPI, TEID and IMSI fields 
not reference a valid PDP context, the corresponding multicast subscriber record is 
removed from the M-PDP context. The PDP context look-up is performed in order to 
determine the addresses of the SGSNs serving each multicast subscriber within the 
M-PDP context at step S6. The addresses of the serving SGSNs for each multicast 
subscriber are stored in a list of SGSN addresses at step S7. The list of SGSN 
addresses may contain duplicate entries since several multicast subscribers may be 
located within the same SGSN service area. The GGSN then replicates and forwards 
the incoming multicast message such that it is sent once to each SGSN address in the 
list at step S8. Multicast message forwarding is performed by tunnelling the multicast 
message using the M-TEID (Gn interface) of the M-PDP context and subsequently 
encapsulating the tunnelled message with UDP/IP using the address of each SGSN 
within the list. 

The steps required for performing multicast routing based on the M-PDP 
contexts at the GGSN 3 are summarized as follows: 

(1) The GGSN correlates an incoming multicast message with the 
matching M-PDP context by evaluating each PDP and M-PDP context it has stored 
until a match is found. 



(2) Using the NSAPI and IMSI encapsulated within each multicast 
subscriber record in the M-PDP context, the GGSN 3 performs a look-up of the PDF 
context associated with the multicast subscriber. Should the NSAPI and IMSI not 
reference a valid PDP context, the multicast subscriber is removed from the M-PDP 
context. Having identified the correct PDP context for the multicast subscriber, the 
GGSN 3 adds the address of the SGSN 4 serving that subscriber given in the PDP 
context to a list of SGSN addresses. 

(3) For each unique SGSN address within the list, the GGSN 3 duplicates 
the received multicast message and forwards it to the SGSN using the M-TEID (Gn 
interface) of the M-PDP context and the address of the SGSN taken from the list. 

Thus the multicast message is forwarded only once over each link between 
the GGSN and any number of SGSNs serving multicast subscribers in the group. 

Referring to Fig. 6 once the SGSN 4 receives an incoming message, it 
searches at step SI for a matching M-PDP context based on the M-TEID (i.e. the M- 
TEID for the Gn interface) of the GTP-encapsulated message. Having found an 
M-PDP context that matches the encapsulated message, the SGSN 4 extracts the TI 
and IMSI fields from the first multicast subscriber record in the M-PDP context at 
step S2. At step S3 the SGSN 4 performs a look-up of the MM context referenced by 
the IMSI field of that multicast subscriber record. At step S4 the SGSN checks 
whether the MM state is PMM-CONNECTED or otherwise for that subscriber. If the 
MM state is not PMM-CONNECTED, the SGSN 4 performs a PS Signalling 
Connection Establish procedure in order to bring the MM context to the 
PMM-CONNECTED state. Once the MM context is in the PMM-CONNECTED 
state, the SGSN 4 looks up the PDP context associated with that subscriber at step S5 
using the IMSI and TI values. At step S6 the SGSN extracts the RNC address given 
in the PDP context and adds it to a list of RNC addresses of multicast subscribers 
within the M-PDP context at step S7. The routine returns to step S2 and performs the 
above steps for the next subscriber in the M-PDP context. This is repeated until all of 
the subscribers associated with the M-PDP context have been processed. The result is 
a list of RNC addresses to which the multicast message must be forwarded. At step 
S8 the SGSN 4 forwards a copy of the multicast message once to each unique entry 



within the list of RNC addresses, using a GTP header containing the M-TEID of the 
lu interface. The packet is then encapsulated using UCP/IP and forwarded to each 
RNCs serving subscribers. 

The steps required for performing multicast routing at the SGSN are 
summarized as follows: 

(1) As with conventional N-PDUs received at an SGSN node, the SGSN 
searches for a PDP or M-PDP context that matches the N-PDU based on the TEID or 
M-TEID of the GTP-encapsulated message. Assuming that the received N-PDU is a 
multicast message (i.e. M-PDU), the SGSN finds a matching M-PDP context. 

(2) The SGSN iterates through the multicast subscriber records in the 
M-PDP context and performs a look-up of the MM and PDP context records 
associated with the multicast subscriber record based on the IMS! and TI fields. 
Should the multicast subscriber record not reference a valid MM or PDP context, the 
multicast subscriber is removed from the M-PDP context. 

(3) For the MM context associated with a multicast subscriber record, the 
SGSN checks whether the MM state is PMM-CONNECTED. If the MM state is not 
PMM-CONNECTED, the SGSN performs the PS Signalling Connection Establish 
procedure. 

(4) Once the multicast subscriber is in the PMM-CONNECTED state, the 
SGSN adds the RNC address of the PDP context referenced by the multicast 
subscriber record to a list of RNC addresses. 

(5) The SGSN duplicates and forwards a copy of the multicast message to 
each unique element within the list of RNC addresses using the lu interface M-TEID 
of the M-PDP context. 

Thus the multicast message is forwarded only once over each link between 
the SGSN and any number of RNCs serving multicast subscribers in the group. 

Referring to Fig. 7 once an RNC 6 receives a GTP-encapsulated N-PDU, the 
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RNC checks its list of RAB and M-RAB contexts for a matching record at step SI 
based on the TEID or M-TEID of the GTP header. Assuming that the received 
N-PDU is indeed a muhicast message, the RNC is able to identify the appropriate 
M-RAB context associated with the M-PDU. At step S2, the RNC is then able to 
identify the records of the multicast subscribers from the M-RAB and extracts the 
RAB ID and IMSI from the first subscriber record. At step S3 the RNC then extracts 
the RAB context for that record. The process is then repeated so as to identify all of 
the RAB contexts associated with the subscribers in the M-RAB. The exact 
mechanism of forwarding muhicast messages at step S4 to the Node Bs serving the 
multicast subscribers stored in the RNC M-RAB context is by and large dependant on 
radio resource management. Ihe RNC is the point in the network at which IP 
addressing ceases in the downlink direction. It is the decision of radio resource 
management how best to distribute the muhicast message from the Node B. For 
example this might be done by a broadcast over the wireless link, or by duplication of 
the message and sending over dedicated or common channels. 

Summarising, the steps the RNC 6 needs to perform in order to identify 
multicast messages and distribute these appropriately are the following: 

(1) As with conventional N-PDUs received at an RNC node, the RNC 
searches for a RAB or M-RAB context that matches the N-PDU based on the TEID 
or M-TEID of the GTP-encapsulated message. Assuming that the received N-PDU is 
a multicast message, the RNC finds a matching M-RAB context. 

(2) Based on the multicast subscriber records stored as part of the 
M-RAB, the RNC is able to resolve which subscribers belong to the multicast group. 
The RNC then forwards the multicast messages to the serving Node Bs either on 
dedicated or common channels based on suitable radio resource management 
strategies. 

Location update procedures are required so that the network can track the 
location of subscribers within the network. Due to the fact that M-PDP and M-RAB 
contexts only maintain references to the actual records of multicast subscribers, all 
MM, PDP, RNC and RAB context records are updated in the usual fashion according 
to the location management procedures described in 3GGPTS. This helps to save 



network resources as M-PDP contexts and M-RAB contexts do no need to be updated 
with mobility management details. 

In performing an inter-SGSN update the MM and PDP context information of 
a subscriber must be transferred between the old and new SGSN (see 3GPPTS pg 
64). The procedure of transferring the MM and PDP context records in the context of 
multicast traffic distribution based on M-PDP contexts requires that the old SGSN 
check the PDP context to be transferred for an associated M-PDP context. This is 
easily done by checking whether the M-PDP context identifier field in the PDP 
context is void or not. If the PDP context is associated with an M-PDP context, the 
SGSN must additionally transfer the M-PDP context in addition to the MM and PDP 
contexts. The new SGSN then either establishes a new M-PDP context or updates an 
existing one with the details of the subscriber. 

A similar procedure is carried out in performing the relocation of the serving 
RNC (SRNC). In this case, the source RNC checks whether the RAB information 
elements that are being requested by the target RNC for reallocation contain an 
association with an M-RAB context. If this is the case, the source RNC transfers the 
M-RAB details to the target RNC alongside the RAB information elements of the 
multicast subscriber. At the target RNC, either a new M-RAB is created or an 
existing one updated with the details of the subscriber. 

Referring to Fig. 9 a performance graph of the multicast routing method 
described above generally identified by reference numeral 45. The performance 
graph 45 shows the multicast method 46 in comparison to the conventional m-times 
unicast method 47. The x-axis shows a logarithmic scale of the number of multicast 
users within a Routing Area (RA) of the UMTS network 1 i.e. the area covered by a 
number of cells. The y-axis shows the number of multicast packets sent to the RA 
between the GGSN 3 and an RNC 6 via one SGSN 4. In the existing UMTS 
architecture a PDP context exists for each mobile node connected to the network. 
Accordingly when a multicast packet arrives at the GGSN, it must be copied and 
tunnelled via each PDP context for the subscribers in the group. However, when 
employing the multicast method described above only one dedicated multicast tunnel 
or logical link need be established for the subscribers. Accordingly the multicast 
packet need only be sent once over the UMTS network as shown by line 46. 
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It will be appreciated that where subscribers to the same multicast group are 
served by different SGSNs and RNCs, it will be necessary to establish more than one 
dedicated multicast logical link for that group on the network. Nevertheless, where 
there are two or more subscribers per SGSN or per RNC, network resources can be 
saved by use of the dedicated multicast logical link. In particular, the maximum 
number of multicast logical links needed between the GGSN and SGSNs is equal to 
the number of SGSNs serving subscribers of the group. Similarly, the maximum 
number of multicast logical links needed between one SGSN and RNCs served 
thereby, is equal to the number of RNCs serving subscribers of the group. More 
might be established, however, if different qualities of service need to be provided to 
subscribers of the same multicast group for example. 

Accordingly, in some scenarios the line 46 in Fig. 9 may not necessarily be 
flat, as the multicast packet will need to be copied at the GGSN and SGSN according 
to the number of multicast logical links (M-PDP contexts) required to serve all 
subscribers of the group. Nevertheless in most cases the UMTS muhicast method is 
likely to resuh in far fewer packets by sent across the network than the unicast 
method. 

(2) UM I S Multicast Group Management 

Group management in UMTS requires both support for group establishment 
and administration within the network as well as appropriate inter-operation with 
external networks, since multicast traffic in many cases will originate from external 
networks. Therefore group management for UM I S requires the network to keep track 
of group members within the network and, depending on which groups are present, 
inform external network of what multicast traffic the network wishes to receive. This 
approach is equivalent to the model adopted in IP multicast, the most widely 
deployed multicast protocol in use today. 

Figure 9a shows an IPv4 datagram 50 that comprises an IGMP message 51 
within a header 52. IPv6 datagrams are constructed in similar fashion. Bearing in 
mind that IGMP messages are encapsulated in IP packets as shown and therefore 
cannot be processed by intermediate UMTS network nodes, IGMP or MLD messages 



must traverse from the UE 1 2 to the GGSN 3 before any action in response to the 
join/leave request can be taken. This is clearly inefficient and places additional load 
on the GGSN that already performs many important tasks. Figure 9b illustrates the 
format of IGMP messages. 

Subscribers within the UMTS network 1 may join and leave multicast groups 
using explicit signalling procedures. Should the connection to a multicast subscriber 
become invalid at any stage, the UMTS network 1 performs an implicit leave 
procedure for the multicast subscriber. 

Subscribers use the M-PDP context join procedure to inform the UMTS 
network 1 that they wish to belong to a multicast group. Based on the M-PDP context 
join procedure the UMTS network learns which groups have members within the 
network. 

Subscribers that wish to join a multicast group must previously have activated 
a PDP or secondary PDP context using the standard procedures for PDP context 
activation. Additionally, subscribers that wish to join a multicast group must have an 
activated RNC RAB context prior to issuing an M-PDP context join request. 

Requesting to join an M-PDP context is equivalent to joining a multicast 
group, although no protocol is needed at the IP layer (e.g. MLD or IGMP) to inform 
get GGSN to start forwarding packets from an external PDN. The M-PDP context 
join request requires that the multicast subscriber specify following details: 

- M-PDP type used in external networks (e.g. IP multicast) 

- M-PDP address used in external networks (e.g. 238.255.254.1) 

- Requested QoS profile 

- Transaction Identifier (TI) of PDP context to be used for multicast message 
forwarding. 

When the UMTS network 1 receives an M-PDP context join request from the 
UE 12, it either adds a multicast subscriber record to any existing M-PDP or M-RAB 
context records at the SGSN 4, GGSN 3 and RNC 6 network nodes or creates new 
M-PDP or M-RAB context provided there are no existing multicast contexts with the 
same M-PDP address at the network nodes in question. In the case that new multicast 



contexts must be created, the subscriber wishing to join the group is added to the 
empty list of multicast subscriber records of the newly-created multicast M-PDP or 
M-RAB context. If an M-PDP or M-RAB context had previously been established for 
a particular multicast group, the subscriber wishing to join the group is added to the 
non-empty list of multicast subscriber records. If a new M-PDP context was created 
at the GGSN 3, the GGSN establishes the required inter-operation with external 
networks so that the network can receive multicast traffic for the group, for example 
by sending unicast a join message to a central multicast router. 

Referring to Fig, 1 1 the basic join mechanism of the proposed multicast group 
management scheme based on M-PDP contexts consists of the following steps: 

(1) The UE 12 with an activated PDP context wishing to join a multicast 
group sends the Join M-PDP Context Request message to the SGSN 4 at step SI The 
Join M-PDP Context Request message specifies the M-PDP type, M-PDP address 
and the requested QoS profile Furthermore, the M-PDP context join request 
encapsulates the TI of the PDP context to be used for multicast message forwarding. 

(2) The SGSN 4 may (optionally) validate the M-PDP context join 
request based on the M-PDP type and M-PDP address provided by the UE. The 
SGSN 4 performs a PDP context look-up using the TI specified in the M-PDP 
context join request in order to check whether a PDP context has been established for 
the subscriber. If the TI does not reference a valid PDP context, the SGSN 4 rejects 
the M-PDP context join request. However, if the TI does reference a valid PDP 
context but the SGSN 4 does not have an M-PDP context for the M-PDP context 
address specified in the Join M-PDP Context Request, the SGSN creates a new 
M-PDP context and adds the UE 12 as a multicast subscriber to the M-PDP context. 
The SGSN also creates and stores a first M-TEID for the new M-PDP context for use 
on the Gn interface. The first M-TEID may be the IP multicast address in an IPv4 
network. This information is stored in a context database in the memory of the 
SGSN. If there is an existing M-PDP context for a given M-PDP context address in 
the context database, the SGSN 4 adds a multicast subscriber record to the existing 
M-PDP context. The first M-TEID of the M-PDP context is inserted into the PDP 
context referenced by the TI. 
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(3) At step S2 the SGSN sends a Join M-PDP Context Request message 
to the GGSN 3 that is specified in the PDP context referenced by the muhicast 
subscriber record. The Join M-PDP Context Request includes the M-PDP type, M- 
lEID, address and requested QoS profile as well as the TEID/NSAPI of the PDP 
5 context to be used for multicast forwarding. The GGSN 3 either creates a new 
M-PDP context or adds the multicast subscriber record to an existing M-PDP context 
in a context database a stored in memory. The identifier (M-TEID) of the M-PDP 
context is inserted into the PDP context referenced by the TEID and NSAPI fields, 

10 (4) If the GGSN 3 does not have an M-PDP context for the M-PDP 

context address specified in the Join M-PDP Context Request in memory, the GGSN 
creates a new M-PDP context and adds the UE 12 as a multicast subscriber to the 
M-PDP context. If there is an existing M-PDP context for a given M-PDP context 
address, the GGSN adds a multicast subscriber record to the existing M-PDP context. 

15 If the GGSN 3 created a new M-PDP context for the multicast subscriber, the GGSN 
activates multicast forwarding with external networks at step S3. In the case of IP 
multicast, the network may deploy any of the protocols in use today (DVMRP, 
MOSPF), the exact mechanism for joining the group is dependant on the protocol 
used for that purpose. At step S4 the GGSN 3 responds to the SGSN 4 with a Join 

20 M-PDP Context Response in order to confirm the activation of the M-PDP context. 

(5) Once the SGSN 4 has received a confirmation that the GGSN has 
performed the required steps for adding a subscriber to a multicast group, the SGSN 
sends a M-RAB Assignment Request at step S5 to the serving RNC 6. The M-RAB 

25 Assignment Request contains the M-PDP address as well as the IMSI and RAB ID 
(which is equivalent to the NSAPI of the PDP context) of the RAB context belonging 
to the multicast subscriber. The RNC checks whether it has an existing M-RAB 
context with the same M-PDP address. If the RNC has an existing M-RAB context in 
a context database in memory, a new multicast subscriber record is added to the 

30 multicast context. Otherwise a new M-RAB context is created and the multicast 
subscriber is inserted into the multicast context. In this case the RNC also creates and 
stores a new second M-TEID for the lu interface for use by the SGSN. The second 
M-TEID may be the IP multicast address in an IPv4 network. The second M-TEID of 
the new M-RAB context is inserted into the RAB context to be referenced for 

35 multicast transmission. The M-RAB Assignment Request does not result in the 
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establishment of radio access bearer between the RNC 6 and the UE 12 since the 
actual transport of multicast messages is done with existing RABs assigned to the 
multicast subscriber. 

(6) At step S6 the RNC 6 confirms that the subscriber has been added to 
an M-RAB by sending an M-RAB Assignment Response to the SGSN 4. Whether or 
not the M-RAB is new multicast logical link, this response includes the second M- 
TEID or new second M-THID to the SGSN. 

The M-PDP Context Update Request and Response messages are needed if 
the RNC has downgraded the requested QoS profile of the multicast subscriber, in 
which case the SGSN must inform the GGSN of the downgraded QoS profile 
assigned to the multicast tunnel. 

(7) At step S7 the SGSN 4 sends the Join M-PDP Context Accept 
message as a confirmation to the UE. 

The M-PDP context request and response messages differ from the 
conventional PDP context request and response messages only in the information 
elements conveyed by the request and response messages. 

When a UE 12 wishes to leave at multicast group it performs an M-PDP 
context leave procedure described in greater detail below. 

In order to leave a multicast group, the multicast subscriber UE 12 sends a 
Leave M-PDP Context Request to the SGSN 4, specifying the M-PDP context details 
and the TI of the PDP context associated with the M-PDP context. The SGSN 4 and 
GGSN 3 network nodes then remove the muUicast subscriber record from the M-PDP 
context or the entire M-PDP context if the multicast subscriber is the last subscriber 
within the M-PDP context. If the entire M-PDP context was removed, the GGSN 
signals to external networks that the network does not wish to receive any further 
multicast traffic for the multicast group. 

The M-PDP context leave procedure is shown in greater detail in Fig. 1 1 and 
consists of following steps: 



(1) At step SI the UE 12 sends a Leave M-PDP Context Request to the 
SGSN 4, specifying the M-PDP context details (M-PDP context type, M-PDP context 
address) and the required multicast subscriber details (TI). 

(2) In response to the message sent at step SI, the SGSN 4 removes the 
appropriate multicast subscriber record from the M-PDP context in the context 
database and removes the entire M-PDP context if the multicast subscriber was the 
last subscriber record within the M-PDP context. The SGSN 4 removes the M-PDP 
context identifier field in the PDP context that was associated with the M-PDP 
context. 

(3) At step S2 The SGSN sends a Leave M-PDP Context Request to the 
GGSN 3, specifying the multicast subscriber record details of the subscriber wishing 
to leave the group (NSAPI and TEID). The Leave M-PDP context Request also 
specifies the first M-TEID to enable the GGSN 3 to identify the M-PDP context. 

(4) In response to the message sent at step S2, the GGSN 3 removes from 
its context database the multicast subscriber record in the M-PDP context for the 
subscriber wishing to leave the group or the entire M-PDP context if the multicast 
subscriber is the last subscription record within the M-PDP context. The GGSN 
removes the M-PDP context identifier field in the PDP context that was associated 
with the M-PDP context. At step S3 the GGSN 3 then terminates multicast 
forwarding with external networks. 

(5) At step S4 the GGSN 3 responds with a Leave M-PDP Context 
Response, confirming that the multicast subscriber has been removed from the group. 

(6) In response to the message sent at step S4, the SGSN 4 sends the 
Leave M-RAB Assignment Request to the serving RNC at step S5 that specifies the 
second M-TEID so that the RNC can identify the M-RAB context. In response to this 
the RNC 6 removes the multicast subscriber from the M-RAB context. Alternatively 
the M-RAB context is deleted if the subscriber was the last entry in the multicast 
subscriber records and the M-RAB identifier is removed from the RAB context used 
by the subscriber. 
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(7) At step S6 The RNC 6 confirms that the subscriber has been removed 
from an M-RAB by sending an M-RAB Assignment Response to the SGSN 4. 

(8) The SGSN 4 confirms to the UE that the M-PDP context deactivation 
is completed at step S7 by sending a Leave M-PDP Context Accept message. 

In order to ensure that the multicast subscriber records within an M-PDP 
context always maintain references to valid MM and PDP contexts, the GGSN 3 and 
SGSN 4 may either perform an implicit multicast leave procedure or activate a new 
PDP context should a multicast subscriber have deactivated a PDP context that is 
associated with an M-PDP context. An implicit multicast leave procedure is shown in 
Fig. 12 and is performed as follows: 

(1) At step SI the UE 12 initiates the PDP Context Deactivation 
procedure as specified in 3GPPTS by sending a Deactivate PDP Context Request 
message to the SGSN 4. The UE 12 specifies the TI of the PDP context to be 
deactivated. 

(2) In response, the SGSN 4 correlates the PDP context deactivation 
request message with its list of stored PDP contexts. Having identified the PDP 
context that the UE 12 would like to deactivate, the SGSN checks whether there is an 
associated M-PDP context by checking for an entry in the M-PDP context identifier 
field. Should the M-PDP context identifier field in the PDP context not be void, the 
SGSN removes the mukicast subscription record of the UE 12 within the appropriate 
M-PDP context. The entire M-PDP context is deleted if the multicast subscriber was 
the last entry within the multicast subscriber record list. 

(3) At step S2 the SGSN 4 sends the Delete PDP Context Request to the 
GGSN 3 according to the standard procedure (see 3GPPTS). 

(4) In response to this message, the GGSN 3 checks whether the PDP 
context to be deleted is associated with an M-PDP context and if this is the case, 
removes the multicast subscription record of the UE in the M-PDP context. The 
GGSN deletes the entire M-PDP context if the subscriber was the last entry within 
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the multicast subscriber list and deactivates multicast message forwarding from 
external networks at step S3. 

(5) At step S4 the GGSN responds to the SGSN with a Delete PDP 
Context Response. 

(6) At step S5 the SGSN 4 sends a Deactivate PDP Context Accept to the 

UE 12. 

(7) The SGSN 4 sends the RAB Assignment Request to the serving RNC 
6 in order to perform radio access bearer release at step S6. The RNC 6 checks 
whether the RAB to be released is associated with an M-RAB context. If this is the 
case the RNC removes the appropriate record from the M-RAB multicast subscriber 
list. The RNC subsequently performs the radio access bearer release procedure. 

The above procedure is equivalent to the standard PDP context deactivation 
procedure apart from the steps that require modification of the M-PDP and RNC 
M-RAB contexts. The implicit multicast leave procedure may be suitable in order to 
avoid delays in delivering multicast packets to all members within the group. On the 
other hand, the GGSN may perform the network-requested PDP context activation 
procedure (see 3GPPTS) in order to re-activate a PDP context that has become 
invalid. This in turn will result in delays in distributing muhicast messages to 
subscribers. 

Some advantages of the above multicast group management scheme are 
that multicast group join/leave latency is reduced as join/leave messages do not 
traverse the entire UMTS network 1 before being processed. As multicast group 
subscription is based on the mechanisms of PDP context activation and deactivation, 
all multicast join/leave messages are acknowledged by the network 1. Multicast 
group management based on the M-PDP context join procedure facilitates integration 
with UMTS-specific mechanisms such as QoS and routing 

It will be apparent that although the invention, both routing and group 
management aspects, have been described with reference to a UMTS network, they 
are applicable to any packet radio network or any network in which the IP layer 
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containing multicast information is not ''visible" to the network such that multicast 
addresses and protocols cannot be used without high overheads on network 
resources. This includes packet radio networks that use tunnel-based mobility 
schemes to route IP datagrams in so-called "all IP" networks. One example is 
hierarchical mobile IP in IPv6 networks (see Chiussi et al "Mobility Management in 
Third-Generation All-IP Networks", IEEE Communications Magazine, September 
2002). 

Furthermore, the invention may be applied between any combination of 
network nodes e.g. between GGSN and SGSN only, or between SGSN and RNC 
only. However, it is believed that the greatest advantages will be achieved by 
applying the methods to the last (in a downlink sense) network layer addressable 
node before the wireless or air interface in the network. 

The references in parentheses in the appended claims are to facilitate ease of 
understanding and in no way should be construed to limit the network type or type of 
network node to those mentioned. The claims extend to all hierarchical equivalent 
nodes in packet radio networks. 

Although the embodiments of the invention described with reference to the 
drawings comprise computer apparatus and methods performed in computer 
apparatus, the invention also extends to computer programs, particularly computer 
programs on or in a carrier, adapted for putting the invention into practice. The 
program may be in the form of source code, object code, a code intermediate source 
and object code such as in partially compiled form, or in any other form suitable for 
use in the implementation of the methods according to the invention. The carrier may 
be any entity or device capable of carrying the program. 

For example, the carrier may comprise a storage medium, such as a ROM, for 
example a CD ROM or a semiconductor ROM, or a magnetic recording medium, for 
example a floppy disc or hard disk. Further, the carrier may be a transmissible carrier 
such as an electrical or optical signal that may be conveyed via electrical or optical 
cable or by radio or other means. 

When the program is embodied in a signal that may be conveyed directly by a 



- 45 - 



cable or other device or means, the carrier may be constituted by such cable or other 
device or means. 

Alternatively, the carrier may be an integrated circuit in which the program is 
embedded, the integrated circuit being adapted for performing, or for use in the 
performance of, the relevant methods. 



- 46 - 



CLAIMS 

1. In a packet radio network comprising a radio access network (RAN) and a 
core network (CN) via which a plurality of mobile nodes may communicate over a 
wireless link with an external packet data network, a method of administering at least 
one muhicast group, subscribers of which are from said plurality of mobile nodes, 
which method comprises the steps of: 

(1) maintaining a first database of subscribers of each multicast group at a 
first node (GGSN) in said packet radio network, said database enabling identification 
of the or each second node (SGSN), or any other network node on the packet radio 
network, responsible for the subscribers of each multicast group; 

(2) providing a mapping between subscribers of each multicast group and 
a number of multicast logical links between the first node (GGSN) and the or each 
second node (SGSN); 

wherein, where there is more than one subscriber of a multicast group served 
by a second node (SGSN), the first database maps those subscribers to a number of 
multicast logical links that less than the number of those subscribers. 

2. A method as claimed in claim 1, wherein for each muhicast group, said 
database maps subscribers thereof to a single multicast logical link per second 
serving node (SGSN). 

3. A method as claimed in claim 1 or 2, wherein identification of the or each 
second node (SGSN) is by means of a pointer for each subscriber in said database, 
each pointer referencing an individual logical link for a subscriber. 

4. A method as claimed in claim 3, wherein each individual logical link is a PDP 
context that identifies the second node (SGSN) serving that subscriber. 

5. A method as claimed in any preceding claim, wherein said multicast logical 
link is at the PDP layer of the packet data network. 

6. A method as claimed in any preceding claim, further comprising the steps of: 
(1) maintaining a second database of subscribers of each multicast group 

at the second node (SGSN) in said packet radio network, said database enabling 
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identification of one or more third nodes (RNC) responsible for the subscribers of 
each muhicast group; 

(2) providing a mapping between subscribers of each multicast group and 
a number of muhicast logical links between the second node (SGSN) and the or each 
third node (RNC); 

wherein, where there is more than one subscriber of a multicast group served 
by a second node (SGSN), the second database maps those subscribers to a number 
of multicast logical links that is less than the number of those subscribers. 

7. A method as claimed in any preceding claim, further comprising the steps of 
maintaining a third database of subscribers of each multicast group at a third node 
(RNC) in said packet radio network, said third database enabling identification the or 
each fourth node (Node B), or any other network node on the packet radio network, 
responsible for the subscribers of each multicast group; 

wherein said third node duphcates multicast data packets according to the 
number of users served by the or each fourth node (Node B) and forwards them on to 
a radio access bearer for transmission over a wireless link. 

8. A method as claimed in any preceding claim, wherein if a user of a mobile 
node wishes to subscribe to a multicast group, the mobile node sends a join request 
message over its individual logical link to the packet radio network so as to cause the 
first, second and/or third nodes to add that mobile node to their databases such that 
multicast packets arriving subsequently at the first node (GGSN) are forwarded to 
said mobile node over said number of multicast logical links to its serving second 
node (SGSN). 

9. A method as claimed in claim 8, wherein said join request message is sent 
firstly to the mobile node's serving node (SGSN) in the packet radio network, 

10. A method as claimed in claim or 8 or 9, wherein if said first, second and/or 
third node does not include an entry for the multicast group that the mobile node 
wishes to join, the method further comprises the steps of establishing a muhicast 
logical link between the core network (CN) and the radio access network (RAN), and 
causing multicast messages to be forwarded from the external packet data network to 
the first node (GGSN) of the packet radio network. 
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11. A method as claimed in claim 10, wherein the step of establishing a multicast 
logical link comprises the steps of: 

(1 ) creating a multicast logical link entry in a database at the second node 
(SGSN) of the mobile node and adding details of the mobile node thereto; 

(2) informing the first node (GGSN) and/or a third node (RNC) of the 
multicast logical link; 

(3) determining whether or not at said first node (GGSN) and/or third 
node (RNC) there is an existing multicast logical link entry for that multicast group; 
and 

(4) if necessary creating a muhicast logical link entry at the first node 
(GGSN) and/or third node (RNC), thereby establishing a multicast logical link 
between the CN gateway node and the RAN gateway node, 

12. A method as claimed in any preceding claim, wherein if a user of a mobile 
node wishes to leave a multicast group, the mobile node sends a leave request 
message over said individual logical link so as to cause said first, second and/or third 
node to remove the mobile node from their databases for that multicast group. 

13. A method as claimed in claim 12, wherein said leave request message is sent 
firstly to the mobile node's serving node (SGSN). 

14. A method as claimed in claim 12 or 13, further comprising the step of tearing 
down the or each multicast logical link between the CN and RAN upon receipt of 
said leave request message if said mobile node is the last subscriber in the group. 

15. A method as claimed in any preceding claim, further comprising the step 
upon receipt of a deactivation message for a mobile node's individual logical link, of 
ascertaining whether or not that mobile node is a subscriber of any multicast groups, 
and if so, removing that mobile node from the or each multicast logical link of which 
it is a subscriber. 

16. A method as claimed in claim 15, wherein said deactivation message is firstly 
sent to the mobile node's serving node, the method further comprising the steps of 
sending a message to the first node (GGSN) to cause removal of a record of the 
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mobile node's individual logical link, and the first node (GGSN) performing the steps 
of claim 15 to remove the mobile node from the or each multicast logical link of 
which it is a subscriber. 

17. A method as claimed in claim 15 or 16, wherein said deactivation message is 
firstly sent to the mobile node's serving node, the method further comprising the 
steps of sending a message to the third node (RNC) to cause removal of a record of 
the mobile node's individual logical link, and the third node (RNC) performing the 
steps of claim 15 to remove the mobile node from the or each multicast logical link 
of which it is a subscriber. 

18. A method as claimed in any preceding claim, wherein said packet radio 
network is a Universal Mobile Telecommunications System (UMTS), said first node 
is a gateway GPRS support node (GGSN), said second node is a serving GPRS 
support node (SGSN), said third node is a radio network controller (RNC), and said 
fourth node is a base station (Node B). 

19. A network node for use in a packet radio network, which network node 
comprises means for storing and executing computer executable instructions for 
performing a method or part of a method as claimed in any preceding claim. 

20. A network node for use in a packet radio network, which network node 
comprises means for storing and executing computer executable instructions for 
performing either: 

(1) any of the first node method steps of any of claims 1 to 18; 

(2) any of the second node method steps of any of claims 1 to 1 8; or 

(3) any of the third node method steps of any of claims 1 to 1 8. 

21. A computer program comprising computer executable instructions for causing 
a computer network node to perform either: 

(1) any of the first node method steps of any of claims 1 to 18; 

(2) any of the second node method steps of any of claims 1 to 18; 

(3) any of the third node method steps of any of claims 1 to 18; or 

(4) any combination of ( 1 ) to (3). 
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22. A computer program as claimed in claim 21, embodied on a record medium, 
stored in a computer memory, embodied in a read-only memory or carried on an 
electrical carrier signal. 




Application No: 
Claims searched: 



GB 0302777.8 
1-22 



• 1 citenL • 
\ Oflice I 

^^^^^^^^^ -r 



7^ • 

5 ] 



Examiner: 
Date of search: 



INVliSTOR IN I'EOPLE 



Emma Porter 
9 July 2003 



Patents Act 1977 : Search Report under Section 17 



Category 


Relevant 
to claims 


Identity of document and passage or figure of particular relevance 


X 


1-22 


WO 03/044984 Al 


(SPRINT SPECTRUM) see whole document, 
especially page 9 lines 175-186, page 10 line 201 
lo page 1 i line zjz and page 12 lines 251-257. 


X 


1-22 


US 2003/0039232 
Al 


(LUCENT) see whole document, especially 
paragraphs 4, 5, 27 and 28, 


X 


1-22 


WO 03/019861 A2 


(ERICSSON) see whole document, especially 
page 1 lines 16-25, page 3 lines 6-22 and page 20 
line 5 onwards. 


X 


1-22 


WO 03/017703 A 1 


(ERICSSON) see whole document, especially 
page 7 lines 23 to page 8 line 19 and page 14 line 
25 to page 5 line 23. 


X 


1-22 


EP 1 071 296 Al 


(ALCATEL) see whole document, especially 
paragraphs 10, 11, 17 and 21. 


X 


1-22 


WO 96/38961 Al 


(TELIA) see whole document, especially page 9 
line 1 to page 13 line 8. 



Categories: 



X Document indicating lack of novelty or inventive step A Document indicating technological background and/or state of the art. 



Y Document indicating lack of inventive step if combined 
with one or more other documents of same category. 

& Member of the same patent family 



P Document published on or after the declared priority date but before the 
filing date of this invention. 

E Patent document published on or after, but with priority date earlier 
than, the filing date of this application. 



Field of Search: 

Search of GB, EP, WO & US patent documents classified in the following areas of the UKC^: 
H4L 



Worldwide search of patent documents classified in the following areas of the IPC^: 



H04L, H04Q 



The fftllffWinS online and other databasf^S have heen used in the pre p aration nf this search rpport- 

Online via EPOQUE: WPI, EPODOC, PAJ 



An Executive Agency of the Department of Trade and Industry 



DERWENT-ACC-NO: 2004-583733 



DERWENT-ACC-NO: 2004-583733 

DERWENT-WEEK: 200457 

COPYRIGHT 2009 DERWENT INFORMATION LTD 

TITLE: Multicast group administration method in 

universal mobile telecommunication system 
network, involves mapping subscribers to 
multicast logical links when more than one 
subscriber of multicast group is served by support 
node 

INVENTOR: AGHVAMI A H; CHUNG Y W ; RUMMLER R M 

PATENT-ASSIGNEE: KINGS COLLEGE LONDON[UNLO] 

PRIORITY-DATA: 2003GB-002777 (February 6, 2003) 
PATENT-FAMILY: 

PUB-NO PUB-DATE LANGUAGE 

GB 2398207 A August 1 1 , 2004 EN 

APPLICATION-DATA: 

PUB-NO APPL-DESCRIPTOR APPL-NO 

GB 2398207A N/A 2003GB- 

002777 



INT-CL-CURRENT: 

TYPE IPC DATE 

CIPS H04L12/18 20060101 



file:///CI/Documents%20and%20Settings/AMoorthy/My%20.. .5909_2009-02-09_GB_2398207_A_M_AccessibleVersion.htm (1 of 3)2/9/09 1:47:49 PM 



APPL-DATE 

February 6, 
2003 



DERWENT-ACC-NO: 2004-583733 



CIPS H04L12/24 20060101 



ABSTRACTED-PUB-NO: GB 2398207 A 
BASIC-ABSTRACT: 

NOVELTY - A mapping between subscribers of each multicast group and 
multicast logical links is provided between a gateway general packet radio 
service (GPRS) support node (GGSN) (3) and a serving GPRS support node 
(SGSN) (4). When more than one subscriber of the multicast group is served 
by the SGSN, the subscribers are mapped to the logical links that serve as 
packet data protocol (PDP) layers of a packet radio network. 

DESCRIPTION - INDEPENDENT CLAIMS are also included for the 
following: 

(1) network node; and 

(2) network node operation program. 

USE - For administering multicast group in packet radio networks such as 
universal mobile telecommunication system (UMTS) network providing 
user such as businessmen in hotel, to access external packet data networks 
such as internet, LAN, WAN, external host, service providers using mobile 
devices such as cellular phone, personal digital assistant, notebook 
computer, digital camera for receiving information related to webcast, video 
conference, file, stock quotes, internet audio, sports event and multimedia. 

ADVANTAGE - The inherent lack of support for resource-efficient 
multicast message delivery is overcome by establishing tunnels across 
interfaces that map to multicast group, thus duplicate transmission of 
multicast messages across the interfaces of the network is avoided reliably. 
Since the nodes in the network do not need internet group multicast protocol 
(IGMP), multicast listener discovery (MLD) protocol or internet protocol 
(IP) multicast group management protocol to handle multicast traffic 
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arriving external packet data networks, processing overhead on the network 
is reduced effectively. 

DESCRIPTION OF DRAWING(S) - The figure shows a schematic view of 
the universal mobile telecommunication system network. 



packet radio network (1) 



core network (2) 



gateway general packet radio service support node (3) 



packet data network (8) 
user equipment (12) 



CHOSEN-DRAWING: Dwg.1/12 

TITLE-TERMS: GROUP ADMINISTER METHOD 

UNIVERSAL MOBILE 
TELECOMMUNICATION SYSTEM 
NETWORK MAP SUBSCRIBER LOGIC LINK 
MORE ONE SERVE SUPPORT NODE 



DERWENT-CLASS: WOl W02 



EPI-CODES: W01-A03B; W01-A06E1A; W01-A06G2; W01-B05A1A; 
W02-C03C1A; 

SECONDARY-ACC-NO: 

Non-CPI Secondary Accession Numbers: 2004-461376 



file:///CI/Documents%20and%20Settings/AMoorthy/My%20.. .5909_2009-02-09_GB_2398207_A_M_AccessibleVersion.htm (3 of 3)2/9/09 1:47:49 PM 



